feat(pi-admission): add standalone pre-history admission example - #38

Summary

Adds projects/pi-admission/, a standalone use-case example showing why content
must be admitted before Pi publishes it to live history or saves it to JSONL,
then independently enforced at OpenShell network egress.

• Runs unmodified Pi in an unmodified OpenShell sandbox.
• Uses one small Rust process for authenticated HTTPS admission and authenticated
  OpenShell gRPC middleware.
• Replaces example.com email addresses with [EMAIL], denies SSN-shaped
  synthetic values, and evaluates decoded content with deny-first semantics.
• Issues short-lived Ed25519 receipts bound to ordered user/tool text,
  destination, sandbox, policy identity, and expiry.
• Keeps the example self-contained; it has no Egress Gate imports, runtime paths,
  CI dependencies, or documentation links.
• Adds dedicated Python, Rust, and TypeScript CI.

This refresh replaces the previous Egress Gate-based PR history with one commit
on current main. It does not delete or otherwise modify the Egress Gate project
that exists on main.

Flow

flowchart LR
    C[Pending candidate] --> A[Authenticated HTTPS admission]
    A -->|deny| D[Not published or saved]
    A -->|allow or replace| H[Pi live history and JSONL]
    H --> F[Approve provider context]
    F --> R[Signed short-lived receipt]
    R --> Q[OpenShell egress request]
    Q --> M[Authenticated gRPC middleware]
    M -->|verify receipt and policy| P[Credentials attached and provider request sent]
    M -->|reject| B[Network request blocked]

sequenceDiagram
    participant U as User or tool
    participant Pi as Pi harness
    participant A as Admission service
    participant O as OpenShell
    participant P as Provider
    U->>Pi: Candidate content
    Pi->>A: Authenticated admission request
    A-->>Pi: Allow, replace, or deny
    alt approved
        Pi->>Pi: Publish and persist final content
        Pi->>A: Approve final provider context
        A-->>Pi: Signed receipt
        Pi->>O: Provider request plus receipt
        O->>A: Authenticated middleware evaluation
        A-->>O: Allow and remove receipt header
        O->>P: Attach credentials and send
    else denied
        Pi->>Pi: Keep candidate out of history and JSONL
    end

Validation

• Python: lock check, Ruff format/lint, 3 pytest tests.
• Rust: cargo fmt --check, Clippy with warnings denied, 7 tests including
  localhost HTTPS transport.
• TypeScript: locked install, type-check, build, 28 behavioral tests.
• Repository dependency-license audit: 32 changed direct dependencies checked,
  0 requiring resolution; native uv/Cargo/npm lock validation passed.
• Documentation: Dev Notes renderer tests and full site build passed.
• OpenShell v0.0.116 local gateway: connected and authenticated over mTLS.
• Shell, YAML, and diff checks passed.

The paid real-model workflow was not run because this checkout has no .env or
operator-owned models.json. The README keeps ./demo.sh verify as the explicit
remaining acceptance gate; fixture-backed tests are not presented as live model
evidence.

LOC breakdown

For equivalent service/setup functionality, the previous Egress Gate-integrated
implementation was 3,643 handwritten lines versus 1,888 here (Rust service plus
setup helpers), a reduction of about 48%. The TypeScript harness remains intact
to preserve timing, replay metadata, compaction, cancellation, and history-write
evidence.

Review notes

• The fixed regex policy is illustrative, text-only, and intentionally not a
  production DLP or identity-validation system.
• Unsupported request structures fail closed.
• Receipts bind the documented user/tool projection, not every provider-body byte
  or all assistant/system history.
• Tool-result admission cannot reverse tool side effects.
• The history guarantee applies to the controlled harness, not compromised
  same-authority code.